ETH2.0: Attestation committee

We can improve the stability of this design by requiring every block to also be attested by a committee: to build a block with parent B, one must first gather signatures from, say, at least 1/2 of a set of M validators, which is itself pseudorandomly sampled from V based on the value of R. This makes forking less likely, as it means that a relatively large number of validators need to collude to make a fork.

The “naive” version of the RANDAO beacon does have a vulnerability to attacker path selection, and only has 51% attack resilience up to α ≈ 0.36

However, this can be largely remedied by requiring a committee of notaries to verify each block (which is already a prudent idea because it reduces forking); adding an extra 4-of-4 notary committee can by itself increase resilience to α ≈ 0.455

However, going too far in this direction compromises the goal of lacking an in-protocol liveness threshold.

Adding a cryptoeconomic aggregate signature, or BLS/STARK-based aggregate signature, would make reversion attempts even more expensive

Resources

Enforcement of signature aggregation in block proposal for less fork

With skipping rule

Analysis

NEAR

Network-level attack

Assumption: committee members are known

... to be able to assign blame and levy penalties in the event of provable misbehavior (which unfortunately precludes the use of VRFs)

Link each validator’s ID to the IP addresses of their nodes through

signature aggregation scheme (e.g. Handel)

DoSing validators that don’t collude/refuse to be bribed to attack a shard with a majority-dishonest committee

Signature aggregation

BLS

Aggregation protocol

1. Signature-based private sortition to elect aggregators (16 in expectation)

2. Attestors send attestations only to a subnet

3. Aggregators send the aggregated attestation to the global network

4. Block proposers include (aggregated) attestations AMAP to maximize the rewards

Previous proposals

Signature aggregation scheme intended as a possible alternative to BLS

Notes

If there is no block created at a slot (in your canonical chain), you can attest to skip-block.

If we do not allow this,

1. The protocol suffer from non-observable nothing-at-stake

2. The security too much depends on the block proposer (e.g. vulnerable to adaptive corruption on the proposers,

Adversary (<1/3) can frequently get >1/3 of proposing slots, making forks all of whose FFG score end up with <2/3

Also, bouncing attack will be much easier

Since the crosslink is different from committee to committee, signature can be aggregated only within a single committee

Only attestations included in a block is counted in FFG (i.e. on-chain voting for on-chain finality)

All of them are counted in LMD GHOST